home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc977.txt < prev    next >
Text File  |  1994-08-01  |  54KB  |  1,540 lines
  1.  
  2.  
  3. Network Working Group                      Brian Kantor (U.C. San Diego)
  4. Request for Comments: 977                   Phil Lapsley (U.C. Berkeley)
  5.                                                            February 1986
  6.  
  7.                      Network News Transfer Protocol
  8.                                     
  9.                 A Proposed Standard for the Stream-Based
  10.                           Transmission of News
  11.  
  12. Status of This Memo
  13.  
  14.    NNTP specifies a protocol for the distribution, inquiry, retrieval,
  15.    and posting of news articles using a reliable stream-based
  16.    transmission of news among the ARPA-Internet community.  NNTP is
  17.    designed so that news articles are stored in a central database
  18.    allowing a subscriber to select only those items he wishes to read.
  19.    Indexing, cross-referencing, and expiration of aged messages are also
  20.    provided. This RFC suggests a proposed protocol for the ARPA-Internet
  21.    community, and requests discussion and suggestions for improvements.
  22.    Distribution of this memo is unlimited.
  23.  
  24. 1.  Introduction
  25.  
  26.    For many years, the ARPA-Internet community has supported the
  27.    distribution of bulletins, information, and data in a timely fashion
  28.    to thousands of participants.  We collectively refer to such items of
  29.    information as "news".  Such news provides for the rapid
  30.    dissemination of items of interest such as software bug fixes, new
  31.    product reviews, technical tips, and programming pointers, as well as
  32.    rapid-fire discussions of matters of concern to the working computer
  33.    professional. News is very popular among its readers.
  34.  
  35.    There are popularly two methods of distributing such news: the
  36.    Internet method of direct mailing, and the USENET news system.
  37.  
  38. 1.1.  Internet Mailing Lists
  39.  
  40.    The Internet community distributes news by the use of mailing lists.
  41.    These are lists of subscriber's mailbox addresses and remailing
  42.    sublists of all intended recipients.  These mailing lists operate by
  43.    remailing a copy of the information to be distributed to each
  44.    subscriber on the mailing list.  Such remailing is inefficient when a
  45.    mailing list grows beyond a dozen or so people, since sending a
  46.    separate copy to each of the subscribers occupies large quantities of
  47.    network bandwidth, CPU resources, and significant amounts of disk
  48.    storage at the destination host.  There is also a significant problem
  49.    in maintenance of the list itself: as subscribers move from one job
  50.    to another; as new subscribers join and old ones leave; and as hosts
  51.    come in and out of service.
  52.  
  53.  
  54.  
  55.  
  56. Kantor & Lapsley                                                [Page 1]
  57.  
  58.  
  59.  
  60. RFC 977                                                    February 1986
  61. Network News Transfer Protocol
  62.  
  63.  
  64. 1.2.  The USENET News System
  65.  
  66.    Clearly, a worthwhile reduction of the amount of these resources used
  67.    can be achieved if articles are stored in a central database on the
  68.    receiving host instead of in each subscriber's mailbox. The USENET
  69.    news system provides a method of doing just this.  There is a central
  70.    repository of the news articles in one place (customarily a spool
  71.    directory of some sort), and a set of programs that allow a
  72.    subscriber to select those items he wishes to read.  Indexing,
  73.    cross-referencing, and expiration of aged messages are also provided.
  74.  
  75. 1.3.  Central Storage of News
  76.  
  77.    For clusters of hosts connected together by fast local area networks
  78.    (such as Ethernet), it makes even more sense to consolidate news
  79.    distribution onto one (or a very few) hosts, and to allow access to
  80.    these news articles using a server and client model.  Subscribers may
  81.    then request only the articles they wish to see, without having to
  82.    wastefully duplicate the storage of a copy of each item on each host.
  83.  
  84. 1.4.  A Central News Server
  85.  
  86.    A way to achieve these economies is to have a central computer system
  87.    that can provide news service to the other systems on the local area
  88.    network.  Such a server would manage the collection of news articles
  89.    and index files, with each person who desires to read news bulletins
  90.    doing so over the LAN.  For a large cluster of computer systems, the
  91.    savings in total disk space is clearly worthwhile.  Also, this allows
  92.    workstations with limited disk storage space to participate in the
  93.    news without incoming items consuming oppressive amounts of the
  94.    workstation's disk storage.
  95.  
  96.    We have heard rumors of somewhat successful attempts to provide
  97.    centralized news service using IBIS and other shared or distributed
  98.    file systems.  While it is possible that such a distributed file
  99.    system implementation might work well with a group of similar
  100.    computers running nearly identical operating systems, such a scheme
  101.    is not general enough to offer service to a wide range of client
  102.    systems, especially when many diverse operating systems may be in use
  103.    among a group of clients.  There are few (if any) shared or networked
  104.    file systems that can offer the generality of service that stream
  105.    connections using Internet TCP provide, particularly when a wide
  106.    range of host hardware and operating systems are considered.
  107.  
  108.    NNTP specifies a protocol for the distribution, inquiry, retrieval,
  109.    and posting of news articles using a reliable stream (such as TCP)
  110.    server-client model. NNTP is designed so that news articles need only
  111.  
  112.  
  113. Kantor & Lapsley                                                [Page 2]
  114.  
  115.  
  116.  
  117. RFC 977                                                    February 1986
  118. Network News Transfer Protocol
  119.  
  120.  
  121.    be stored on one (presumably central) host, and subscribers on other
  122.    hosts attached to the LAN may read news articles using stream
  123.    connections to the news host.
  124.  
  125.    NNTP is modelled upon the news article specifications in RFC 850,
  126.    which describes the USENET news system.  However, NNTP makes few
  127.    demands upon the structure, content, or storage of news articles, and
  128.    thus we believe it easily can be adapted to other non-USENET news
  129.    systems.
  130.  
  131.    Typically, the NNTP server runs as a background process on one host,
  132.    and would accept connections from other hosts on the LAN.  This works
  133.    well when there are a number of small computer systems (such as
  134.    workstations, with only one or at most a few users each), and a large
  135.    central server.
  136.  
  137. 1.5.  Intermediate News Servers
  138.  
  139.    For clusters of machines with many users (as might be the case in a
  140.    university or large industrial environment), an intermediate server
  141.    might be used.  This intermediate or "slave" server runs on each
  142.    computer system, and is responsible for mediating news reading
  143.    requests and performing local caching of recently-retrieved news
  144.    articles.
  145.  
  146.    Typically, a client attempting to obtain news service would first
  147.    attempt to connect to the news service port on the local machine.  If
  148.    this attempt were unsuccessful, indicating a failed server, an
  149.    installation might choose to either deny news access, or to permit
  150.    connection to the central "master" news server.
  151.  
  152.    For workstations or other small systems, direct connection to the
  153.    master server would probably be the normal manner of operation.
  154.  
  155.    This specification does not cover the operation of slave NNTP
  156.    servers.  We merely suggest that slave servers are a logical addition
  157.    to NNTP server usage which would enhance operation on large local
  158.    area networks.
  159.  
  160. 1.6.  News Distribution
  161.  
  162.    NNTP has commands which provide a straightforward method of
  163.    exchanging articles between cooperating hosts. Hosts which are well
  164.    connected on a local area or other fast network and who wish to
  165.    actually obtain copies of news articles for local storage might well
  166.    find NNTP to be a more efficient way to distribute news than more
  167.    traditional transfer methods (such as UUCP).
  168.  
  169.  
  170. Kantor & Lapsley                                                [Page 3]
  171.  
  172.  
  173.  
  174. RFC 977                                                    February 1986
  175. Network News Transfer Protocol
  176.  
  177.  
  178.    In the traditional method of distributing news articles, news is
  179.    propagated from host to host by flooding - that is, each host will
  180.    send all its new news articles on to each host that it feeds.  These
  181.    hosts will then in turn send these new articles on to other hosts
  182.    that they feed.  Clearly, sending articles that a host already has
  183.    obtained a copy of from another feed (many hosts that receive news
  184.    are redundantly fed) again is a waste of time and communications
  185.    resources, but for transport mechanisms that are single-transaction
  186.    based rather than interactive (such as UUCP in the UNIX-world <1>),
  187.    distribution time is diminished by sending all articles and having
  188.    the receiving host simply discard the duplicates.  This is an
  189.    especially true when communications sessions are limited to once a
  190.    day.
  191.  
  192.    Using NNTP, hosts exchanging news articles have an interactive
  193.    mechanism for deciding which articles are to be transmitted.  A host
  194.    desiring new news, or which has new news to send, will typically
  195.    contact one or more of its neighbors using NNTP.  First it will
  196.    inquire if any new news groups have been created on the serving host
  197.    by means of the NEWGROUPS command.  If so, and those are appropriate
  198.    or desired (as established by local site-dependent rules), those new
  199.    newsgroups can be created.
  200.  
  201.    The client host will then inquire as to which new articles have
  202.    arrived in all or some of the newsgroups that it desires to receive,
  203.    using the NEWNEWS command.  It will receive a list of new articles
  204.    from the server, and can request transmission of those articles that
  205.    it desires and does not already have.
  206.  
  207.    Finally, the client can advise the server of those new articles which
  208.    the client has recently received.  The server will indicate those
  209.    articles that it has already obtained copies of, and which articles
  210.    should be sent to add to its collection.
  211.  
  212.    In this manner, only those articles which are not duplicates and
  213.    which are desired are transferred.
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227. Kantor & Lapsley                                                [Page 4]
  228.  
  229.  
  230.  
  231. RFC 977                                                    February 1986
  232. Network News Transfer Protocol
  233.  
  234.  
  235. 2.  The NNTP Specification
  236.  
  237. 2.1.  Overview
  238.  
  239.    The news server specified by this document uses a stream connection
  240.    (such as TCP) and SMTP-like commands and responses.  It is designed
  241.    to accept connections from hosts, and to provide a simple interface
  242.    to the news database.
  243.  
  244.    This server is only an interface between programs and the news
  245.    databases. It does not perform any user interaction or presentation-
  246.    level functions. These "user-friendly" functions are better left to
  247.    the client programs, which have a better understanding of the
  248.    environment in which they are operating.
  249.  
  250.    When used via Internet TCP, the contact port assigned for this
  251.    service is 119.
  252.  
  253. 2.2.  Character Codes
  254.  
  255.    Commands and replies are composed of characters from the ASCII
  256.    character set.  When the transport service provides an 8-bit byte
  257.    (octet) transmission channel, each 7-bit character is transmitted
  258.    right justified in an octet with the high order bit cleared to zero.
  259.  
  260. 2.3.  Commands
  261.  
  262.    Commands consist of a command word, which in some cases may be
  263.    followed by a parameter.  Commands with parameters must separate the
  264.    parameters from each other and from the command by one or more space
  265.    or tab characters.  Command lines must be complete with all required
  266.    parameters, and may not contain more than one command.
  267.  
  268.    Commands and command parameters are not case sensitive. That is, a
  269.    command or parameter word may be upper case, lower case, or any
  270.    mixture of upper and lower case.
  271.  
  272.    Each command line must be terminated by a CR-LF (Carriage Return -
  273.    Line Feed) pair.
  274.  
  275.    Command lines shall not exceed 512 characters in length, counting all
  276.    characters including spaces, separators, punctuation, and the
  277.    trailing CR-LF (thus there are 510 characters maximum allowed for the
  278.    command and its parameters).  There is no provision for continuation
  279.    command lines.
  280.  
  281.  
  282.  
  283.  
  284. Kantor & Lapsley                                                [Page 5]
  285.  
  286.  
  287.  
  288. RFC 977                                                    February 1986
  289. Network News Transfer Protocol
  290.  
  291.  
  292. 2.4.  Responses
  293.  
  294.    Responses are of two kinds, textual and status.
  295.  
  296. 2.4.1.  Text Responses
  297.  
  298.    Text is sent only after a numeric status response line has been sent
  299.    that indicates that text will follow.  Text is sent as a series of
  300.    successive lines of textual matter, each terminated with CR-LF pair.
  301.    A single line containing only a period (.) is sent to indicate the
  302.    end of the text (i.e., the server will send a CR-LF pair at the end
  303.    of the last line of text, a period, and another CR-LF pair).
  304.  
  305.    If the text contained a period as the first character of the text
  306.    line in the original, that first period is doubled.  Therefore, the
  307.    client must examine the first character of each line received, and
  308.    for those beginning with a period, determine either that this is the
  309.    end of the text or whether to collapse the doubled period to a single
  310.    one.
  311.  
  312.    The intention is that text messages will usually be displayed on the
  313.    user's terminal whereas command/status responses will be interpreted
  314.    by the client program before any possible display is done.
  315.  
  316. 2.4.2.  Status Responses
  317.  
  318.    These are status reports from the server and indicate the response to
  319.    the last command received from the client.
  320.  
  321.    Status response lines begin with a 3 digit numeric code which is
  322.    sufficient to distinguish all responses.  Some of these may herald
  323.    the subsequent transmission of text.
  324.  
  325.    The first digit of the response broadly indicates the success,
  326.    failure, or progress of the previous command.
  327.  
  328.       1xx - Informative message
  329.       2xx - Command ok
  330.       3xx - Command ok so far, send the rest of it.
  331.       4xx - Command was correct, but couldn't be performed for
  332.             some reason.
  333.       5xx - Command unimplemented, or incorrect, or a serious
  334.             program error occurred.
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341. Kantor & Lapsley                                                [Page 6]
  342.  
  343.  
  344.  
  345. RFC 977                                                    February 1986
  346. Network News Transfer Protocol
  347.  
  348.  
  349.    The next digit in the code indicates the function response category.
  350.  
  351.       x0x - Connection, setup, and miscellaneous messages
  352.       x1x - Newsgroup selection
  353.       x2x - Article selection
  354.       x3x - Distribution functions
  355.       x4x - Posting
  356.       x8x - Nonstandard (private implementation) extensions
  357.       x9x - Debugging output
  358.  
  359.    The exact response codes that should be expected from each command
  360.    are detailed in the description of that command.  In addition, below
  361.    is listed a general set of response codes that may be received at any
  362.    time.
  363.  
  364.    Certain status responses contain parameters such as numbers and
  365.    names. The number and type of such parameters is fixed for each
  366.    response code to simplify interpretation of the response.
  367.  
  368.    Parameters are separated from the numeric response code and from each
  369.    other by a single space. All numeric parameters are decimal, and may
  370.    have leading zeros. All string parameters begin after the separating
  371.    space, and end before the following separating space or the CR-LF
  372.    pair at the end of the line. (String parameters may not, therefore,
  373.    contain spaces.) All text, if any, in the response which is not a
  374.    parameter of the response must follow and be separated from the last
  375.    parameter by a space.  Also, note that the text following a response
  376.    number may vary in different implementations of the server. The
  377.    3-digit numeric code should be used to determine what response was
  378.    sent.
  379.  
  380.    Response codes not specified in this standard may be used for any
  381.    installation-specific additional commands also not specified. These
  382.    should be chosen to fit the pattern of x8x specified above.  (Note
  383.    that debugging is provided for explicitly in the x9x response codes.)
  384.    The use of unspecified response codes for standard commands is
  385.    prohibited.
  386.  
  387.    We have provided a response pattern x9x for debugging.  Since much
  388.    debugging output may be classed as "informative messages", we would
  389.    expect, therefore, that responses 190 through 199 would be used for
  390.    various debugging outputs.  There is no requirement in this
  391.    specification for debugging output, but if such is provided over the
  392.    connected stream, it must use these response codes.  If appropriate
  393.    to a specific implementation, other x9x codes may be used for
  394.    debugging.  (An example might be to use e.g., 290 to acknowledge a
  395.    remote debugging request.)
  396.  
  397.  
  398. Kantor & Lapsley                                                [Page 7]
  399.  
  400.  
  401.  
  402. RFC 977                                                    February 1986
  403. Network News Transfer Protocol
  404.  
  405.  
  406. 2.4.3.  General Responses
  407.  
  408.    The following is a list of general response codes that may be sent by
  409.    the NNTP server.  These are not specific to any one command, but may
  410.    be returned as the result of a connection, a failure, or some unusual
  411.    condition.
  412.  
  413.    In general, 1xx codes may be ignored or displayed as desired;  code
  414.    200 or 201 is sent upon initial connection to the NNTP server
  415.    depending upon posting permission; code 400 will be sent when the
  416.    NNTP server discontinues service (by operator request, for example);
  417.    and 5xx codes indicate that the command could not be performed for
  418.    some unusual reason.
  419.  
  420.       100 help text
  421.       190
  422.         through
  423.       199 debug output
  424.  
  425.       200 server ready - posting allowed
  426.       201 server ready - no posting allowed
  427.  
  428.       400 service discontinued
  429.  
  430.       500 command not recognized
  431.       501 command syntax error
  432.       502 access restriction or permission denied
  433.       503 program fault - command not performed
  434.  
  435. 3.  Command and Response Details
  436.  
  437.    On the following pages are descriptions of each command recognized by
  438.    the NNTP server and the responses which will be returned by those
  439.    commands.
  440.  
  441.    Each command is shown in upper case for clarity, although case is
  442.    ignored in the interpretation of commands by the NNTP server.  Any
  443.    parameters are shown in lower case.  A parameter shown in [square
  444.    brackets] is optional.  For example, [GMT] indicates that the
  445.    triglyph GMT may present or omitted.
  446.  
  447.    Every command described in this section must be implemented by all
  448.    NNTP servers.
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455. Kantor & Lapsley                                                [Page 8]
  456.  
  457.  
  458.  
  459. RFC 977                                                    February 1986
  460. Network News Transfer Protocol
  461.  
  462.  
  463.    There is no prohibition against additional commands being added;
  464.    however, it is recommended that any such unspecified command begin
  465.    with the letter "X" to avoid conflict with later revisions of this
  466.    specification.
  467.  
  468.    Implementors are reminded that such additional commands may not
  469.    redefine specified status response codes.  Using additional
  470.    unspecified responses for standard commands is also prohibited.
  471.  
  472. 3.1.  The ARTICLE, BODY, HEAD, and STAT commands
  473.  
  474.    There are two forms to the ARTICLE command (and the related BODY,
  475.    HEAD, and STAT commands), each using a different method of specifying
  476.    which article is to be retrieved.  When the ARTICLE command is
  477.    followed by a message-id in angle brackets ("<" and ">"), the first
  478.    form of the command is used; when a numeric parameter or no parameter
  479.    is supplied, the second form is invoked.
  480.  
  481.    The text of the article is returned as a textual response, as
  482.    described earlier in this document.
  483.  
  484.    The HEAD and BODY commands are identical to the ARTICLE command
  485.    except that they respectively return only the header lines or text
  486.    body of the article.
  487.  
  488.    The STAT command is similar to the ARTICLE command except that no
  489.    text is returned.  When selecting by message number within a group,
  490.    the STAT command serves to set the current article pointer without
  491.    sending text. The returned acknowledgement response will contain the
  492.    message-id, which may be of some value.  Using the STAT command to
  493.    select by message-id is valid but of questionable value, since a
  494.    selection by message-id does NOT alter the "current article pointer".
  495.  
  496. 3.1.1.  ARTICLE (selection by message-id)
  497.  
  498.    ARTICLE <message-id>
  499.  
  500.    Display the header, a blank line, then the body (text) of the
  501.    specified article.  Message-id is the message id of an article as
  502.    shown in that article's header.  It is anticipated that the client
  503.    will obtain the message-id from a list provided by the NEWNEWS
  504.    command, from references contained within another article, or from
  505.    the message-id provided in the response to some other commands.
  506.  
  507.    Please note that the internally-maintained "current article pointer"
  508.    is NOT ALTERED by this command. This is both to facilitate the
  509.    presentation of articles that may be referenced within an article
  510.  
  511.  
  512. Kantor & Lapsley                                                [Page 9]
  513.  
  514.  
  515.  
  516. RFC 977                                                    February 1986
  517. Network News Transfer Protocol
  518.  
  519.  
  520.    being read, and because of the semantic difficulties of determining
  521.    the proper sequence and membership of an article which may have been
  522.    posted to more than one newsgroup.
  523.  
  524. 3.1.2.  ARTICLE (selection by number)
  525.  
  526.    ARTICLE [nnn]
  527.  
  528.    Displays the header, a blank line, then the body (text) of the
  529.    current or specified article.  The optional parameter nnn is the
  530.  
  531.    numeric id of an article in the current newsgroup and must be chosen
  532.    from the range of articles provided when the newsgroup was selected.
  533.    If it is omitted, the current article is assumed.
  534.  
  535.    The internally-maintained "current article pointer" is set by this
  536.    command if a valid article number is specified.
  537.  
  538.    [the following applies to both forms of the article command.] A
  539.    response indicating the current article number, a message-id string,
  540.    and that text is to follow will be returned.
  541.  
  542.    The message-id string returned is an identification string contained
  543.    within angle brackets ("<" and ">"), which is derived from the header
  544.    of the article itself.  The Message-ID header line (required by
  545.    RFC850) from the article must be used to supply this information. If
  546.    the message-id header line is missing from the article, a single
  547.    digit "0" (zero) should be supplied within the angle brackets.
  548.  
  549.    Since the message-id field is unique with each article, it may be
  550.    used by a news reading program to skip duplicate displays of articles
  551.    that have been posted more than once, or to more than one newsgroup.
  552.  
  553. 3.1.3.  Responses
  554.  
  555.    220 n <a> article retrieved - head and body follow
  556.            (n = article number, <a> = message-id)
  557.    221 n <a> article retrieved - head follows
  558.    222 n <a> article retrieved - body follows
  559.    223 n <a> article retrieved - request text separately
  560.    412 no newsgroup has been selected
  561.    420 no current article has been selected
  562.    423 no such article number in this group
  563.    430 no such article found
  564.  
  565.  
  566.  
  567.  
  568.  
  569. Kantor & Lapsley                                               [Page 10]
  570.  
  571.  
  572.  
  573. RFC 977                                                    February 1986
  574. Network News Transfer Protocol
  575.  
  576.  
  577. 3.2.  The GROUP command
  578.  
  579. 3.2.1.  GROUP
  580.  
  581.    GROUP ggg
  582.  
  583.    The required parameter ggg is the name of the newsgroup to be
  584.    selected (e.g. "net.news").  A list of valid newsgroups may be
  585.    obtained from the LIST command.
  586.  
  587.    The successful selection response will return the article numbers of
  588.    the first and last articles in the group, and an estimate of the
  589.    number of articles on file in the group.  It is not necessary that
  590.    the estimate be correct, although that is helpful; it must only be
  591.    equal to or larger than the actual number of articles on file.  (Some
  592.    implementations will actually count the number of articles on file.
  593.    Others will just subtract first article number from last to get an
  594.    estimate.)
  595.  
  596.    When a valid group is selected by means of this command, the
  597.    internally maintained "current article pointer" is set to the first
  598.    article in the group.  If an invalid group is specified, the
  599.    previously selected group and article remain selected.  If an empty
  600.    newsgroup is selected, the "current article pointer" is in an
  601.    indeterminate state and should not be used.
  602.  
  603.    Note that the name of the newsgroup is not case-dependent.  It must
  604.    otherwise match a newsgroup obtained from the LIST command or an
  605.    error will result.
  606.  
  607. 3.2.2.  Responses
  608.  
  609.    211 n f l s group selected
  610.            (n = estimated number of articles in group,
  611.            f = first article number in the group,
  612.            l = last article number in the group,
  613.            s = name of the group.)
  614.    411 no such news group
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626. Kantor & Lapsley                                               [Page 11]
  627.  
  628.  
  629.  
  630. RFC 977                                                    February 1986
  631. Network News Transfer Protocol
  632.  
  633.  
  634. 3.3.  The HELP command
  635.  
  636. 3.3.1.  HELP
  637.  
  638.    HELP
  639.  
  640.    Provides a short summary of commands that are understood by this
  641.    implementation of the server. The help text will be presented as a
  642.    textual response, terminated by a single period on a line by itself.
  643.  
  644.    3.3.2.  Responses
  645.  
  646.    100 help text follows
  647.  
  648. 3.4.  The IHAVE command
  649.  
  650. 3.4.1.  IHAVE
  651.  
  652.    IHAVE <messageid>
  653.  
  654.    The IHAVE command informs the server that the client has an article
  655.    whose id is <messageid>.  If the server desires a copy of that
  656.    article, it will return a response instructing the client to send the
  657.    entire article.  If the server does not want the article (if, for
  658.    example, the server already has a copy of it), a response indicating
  659.    that the article is not wanted will be returned.
  660.  
  661.    If transmission of the article is requested, the client should send
  662.    the entire article, including header and body, in the manner
  663.    specified for text transmission from the server. A response code
  664.    indicating success or failure of the transferral of the article will
  665.    be returned.
  666.  
  667.    This function differs from the POST command in that it is intended
  668.    for use in transferring already-posted articles between hosts.
  669.    Normally it will not be used when the client is a personal
  670.    newsreading program.  In particular, this function will invoke the
  671.    server's news posting program with the appropriate settings (flags,
  672.    options, etc) to indicate that the forthcoming article is being
  673.    forwarded from another host.
  674.  
  675.    The server may, however, elect not to post or forward the article if
  676.    after further examination of the article it deems it inappropriate to
  677.    do so.  The 436 or 437 error codes may be returned as appropriate to
  678.    the situation.
  679.  
  680.    Reasons for such subsequent rejection of an article may include such
  681.  
  682.  
  683. Kantor & Lapsley                                               [Page 12]
  684.  
  685.  
  686.  
  687. RFC 977                                                    February 1986
  688. Network News Transfer Protocol
  689.  
  690.  
  691.    problems as inappropriate newsgroups or distributions, disk space
  692.    limitations, article lengths, garbled headers, and the like.  These
  693.    are typically restrictions enforced by the server host's news
  694.    software and not necessarily the NNTP server itself.
  695.  
  696. 3.4.2.  Responses
  697.  
  698.    235 article transferred ok
  699.    335 send article to be transferred.  End with <CR-LF>.<CR-LF>
  700.    435 article not wanted - do not send it
  701.    436 transfer failed - try again later
  702.    437 article rejected - do not try again
  703.  
  704.    An implementation note:
  705.  
  706.    Because some host news posting software may not be able to decide
  707.    immediately that an article is inappropriate for posting or
  708.    forwarding, it is acceptable to acknowledge the successful transfer
  709.    of the article and to later silently discard it.  Thus it is
  710.    permitted to return the 235 acknowledgement code and later discard
  711.    the received article.  This is not a fully satisfactory solution to
  712.    the problem.  Perhaps some implementations will wish to send mail to
  713.    the author of the article in certain of these cases.
  714.  
  715. 3.5.  The LAST command
  716.  
  717. 3.5.1.  LAST
  718.  
  719.    LAST
  720.  
  721.    The internally maintained "current article pointer" is set to the
  722.    previous article in the current newsgroup.  If already positioned at
  723.    the first article of the newsgroup, an error message is returned and
  724.    the current article remains selected.
  725.  
  726.    The internally-maintained "current article pointer" is set by this
  727.    command.
  728.  
  729.    A response indicating the current article number, and a message-id
  730.    string will be returned.  No text is sent in response to this
  731.    command.
  732.  
  733. 3.5.2.  Responses
  734.  
  735.    223 n a article retrieved - request text separately
  736.            (n = article number, a = unique article id)
  737.  
  738.  
  739.  
  740. Kantor & Lapsley                                               [Page 13]
  741.  
  742.  
  743.  
  744. RFC 977                                                    February 1986
  745. Network News Transfer Protocol
  746.  
  747.  
  748.    412 no newsgroup selected
  749.    420 no current article has been selected
  750.    422 no previous article in this group
  751.  
  752. 3.6.  The LIST command
  753.  
  754. 3.6.1.  LIST
  755.  
  756.    LIST
  757.  
  758.    Returns a list of valid newsgroups and associated information.  Each
  759.    newsgroup is sent as a line of text in the following format:
  760.  
  761.       group last first p
  762.  
  763.    where <group> is the name of the newsgroup, <last> is the number of
  764.    the last known article currently in that newsgroup, <first> is the
  765.    number of the first article currently in the newsgroup, and <p> is
  766.    either 'y' or 'n' indicating whether posting to this newsgroup is
  767.    allowed ('y') or prohibited ('n').
  768.  
  769.    The <first> and <last> fields will always be numeric.  They may have
  770.    leading zeros.  If the <last> field evaluates to less than the
  771.    <first> field, there are no articles currently on file in the
  772.    newsgroup.
  773.  
  774.    Note that posting may still be prohibited to a client even though the
  775.    LIST command indicates that posting is permitted to a particular
  776.    newsgroup. See the POST command for an explanation of client
  777.    prohibitions.  The posting flag exists for each newsgroup because
  778.    some newsgroups are moderated or are digests, and therefore cannot be
  779.    posted to; that is, articles posted to them must be mailed to a
  780.    moderator who will post them for the submitter.  This is independent
  781.    of the posting permission granted to a client by the NNTP server.
  782.  
  783.    Please note that an empty list (i.e., the text body returned by this
  784.    command consists only of the terminating period) is a possible valid
  785.    response, and indicates that there are currently no valid newsgroups.
  786.  
  787. 3.6.2.  Responses
  788.  
  789.    215 list of newsgroups follows
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797. Kantor & Lapsley                                               [Page 14]
  798.  
  799.  
  800.  
  801. RFC 977                                                    February 1986
  802. Network News Transfer Protocol
  803.  
  804.  
  805. 3.7.  The NEWGROUPS command
  806.  
  807. 3.7.1.  NEWGROUPS
  808.  
  809.    NEWGROUPS date time [GMT] [<distributions>]
  810.  
  811.    A list of newsgroups created since <date and time> will be listed in
  812.    the same format as the LIST command.
  813.  
  814.    The date is sent as 6 digits in the format YYMMDD, where YY is the
  815.    last two digits of the year, MM is the two digits of the month (with
  816.    leading zero, if appropriate), and DD is the day of the month (with
  817.    leading zero, if appropriate).  The closest century is assumed as
  818.    part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
  819.    1999, 00 is 2000).
  820.  
  821.    Time must also be specified.  It must be as 6 digits HHMMSS with HH
  822.    being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
  823.    00-59.  The time is assumed to be in the server's timezone unless the
  824.    token "GMT" appears, in which case both time and date are evaluated
  825.    at the 0 meridian.
  826.  
  827.    The optional parameter "distributions" is a list of distribution
  828.    groups, enclosed in angle brackets.  If specified, the distribution
  829.    portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
  830.    examined for a match with the distribution categories listed, and
  831.    only those new newsgroups which match will be listed.  If more than
  832.    one distribution group is to be listed, they must be separated by
  833.    commas within the angle brackets.
  834.  
  835.    Please note that an empty list (i.e., the text body returned by this
  836.    command consists only of the terminating period) is a possible valid
  837.    response, and indicates that there are currently no new newsgroups.
  838.  
  839. 3.7.2.  Responses
  840.  
  841.    231 list of new newsgroups follows
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854. Kantor & Lapsley                                               [Page 15]
  855.  
  856.  
  857.  
  858. RFC 977                                                    February 1986
  859. Network News Transfer Protocol
  860.  
  861.  
  862. 3.8.  The NEWNEWS command
  863.  
  864. 3.8.1.  NEWNEWS
  865.  
  866.    NEWNEWS newsgroups date time [GMT] [<distribution>]
  867.  
  868.    A list of message-ids of articles posted or received to the specified
  869.    newsgroup since "date" will be listed. The format of the listing will
  870.    be one message-id per line, as though text were being sent.  A single
  871.    line consisting solely of one period followed by CR-LF will terminate
  872.    the list.
  873.  
  874.    Date and time are in the same format as the NEWGROUPS command.
  875.  
  876.    A newsgroup name containing a "*" (an asterisk) may be specified to
  877.    broaden the article search to some or all newsgroups.  The asterisk
  878.    will be extended to match any part of a newsgroup name (e.g.,
  879.    net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
  880.    if only an asterisk is given as the newsgroup name, all newsgroups
  881.    will be searched for new news.
  882.  
  883.    (Please note that the asterisk "*" expansion is a general
  884.    replacement; in particular, the specification of e.g., net.*.unix
  885.    should be correctly expanded to embrace names such as net.wombat.unix
  886.    and net.whocares.unix.)
  887.  
  888.    Conversely, if no asterisk appears in a given newsgroup name, only
  889.    the specified newsgroup will be searched for new articles. Newsgroup
  890.    names must be chosen from those returned in the listing of available
  891.    groups.  Multiple newsgroup names (including a "*") may be specified
  892.    in this command, separated by a comma.  No comma shall appear after
  893.    the last newsgroup in the list.  [Implementors are cautioned to keep
  894.    the 512 character command length limit in mind.]
  895.  
  896.    The exclamation point ("!") may be used to negate a match. This can
  897.    be used to selectively omit certain newsgroups from an otherwise
  898.    larger list.  For example, a newsgroups specification of
  899.    "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
  900.    all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
  901.    matched.  If used, the exclamation point must appear as the first
  902.    character of the given newsgroup name or pattern.
  903.  
  904.    The optional parameter "distributions" is a list of distribution
  905.    groups, enclosed in angle brackets.  If specified, the distribution
  906.    portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
  907.    be examined for a match with the distribution categories listed, and
  908.    only those articles which have at least one newsgroup belonging to
  909.  
  910.  
  911. Kantor & Lapsley                                               [Page 16]
  912.  
  913.  
  914.  
  915. RFC 977                                                    February 1986
  916. Network News Transfer Protocol
  917.  
  918.  
  919.    the list of distributions will be listed.  If more than one
  920.    distribution group is to be supplied, they must be separated by
  921.    commas within the angle brackets.
  922.  
  923.    The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
  924.    news is discussed in an earlier part of this document.
  925.  
  926.    Please note that an empty list (i.e., the text body returned by this
  927.    command consists only of the terminating period) is a possible valid
  928.    response, and indicates that there is currently no new news.
  929.  
  930. 3.8.2.  Responses
  931.  
  932.    230 list of new articles by message-id follows
  933.  
  934. 3.9.  The NEXT command
  935.  
  936. 3.9.1.  NEXT
  937.  
  938.    NEXT
  939.  
  940.    The internally maintained "current article pointer" is advanced to
  941.    the next article in the current newsgroup.  If no more articles
  942.    remain in the current group, an error message is returned and the
  943.    current article remains selected.
  944.  
  945.    The internally-maintained "current article pointer" is set by this
  946.    command.
  947.  
  948.    A response indicating the current article number, and the message-id
  949.    string will be returned.  No text is sent in response to this
  950.    command.
  951.  
  952. 3.9.2.  Responses
  953.  
  954.    223 n a article retrieved - request text separately
  955.            (n = article number, a = unique article id)
  956.    412 no newsgroup selected
  957.    420 no current article has been selected
  958.    421 no next article in this group
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968. Kantor & Lapsley                                               [Page 17]
  969.  
  970.  
  971.  
  972. RFC 977                                                    February 1986
  973. Network News Transfer Protocol
  974.  
  975.  
  976. 3.10.  The POST command
  977.  
  978. 3.10.1.  POST
  979.  
  980.    POST
  981.  
  982.    If posting is allowed, response code 340 is returned to indicate that
  983.    the article to be posted should be sent. Response code 440 indicates
  984.    that posting is prohibited for some installation-dependent reason.
  985.  
  986.    If posting is permitted, the article should be presented in the
  987.    format specified by RFC850, and should include all required header
  988.    lines. After the article's header and body have been completely sent
  989.    by the client to the server, a further response code will be returned
  990.    to indicate success or failure of the posting attempt.
  991.  
  992.    The text forming the header and body of the message to be posted
  993.    should be sent by the client using the conventions for text received
  994.    from the news server:  A single period (".") on a line indicates the
  995.    end of the text, with lines starting with a period in the original
  996.    text having that period doubled during transmission.
  997.  
  998.    No attempt shall be made by the server to filter characters, fold or
  999.    limit lines, or otherwise process incoming text.  It is our intent
  1000.    that the server just pass the incoming message to be posted to the
  1001.    server installation's news posting software, which is separate from
  1002.    this specification.  See RFC850 for more details.
  1003.  
  1004.    Since most installations will want the client news program to allow
  1005.    the user to prepare his message using some sort of text editor, and
  1006.    transmit it to the server for posting only after it is composed, the
  1007.    client program should take note of the herald message that greeted it
  1008.    when the connection was first established. This message indicates
  1009.    whether postings from that client are permitted or not, and can be
  1010.    used to caution the user that his access is read-only if that is the
  1011.    case. This will prevent the user from wasting a good deal of time
  1012.    composing a message only to find posting of the message was denied.
  1013.    The method and determination of which clients and hosts may post is
  1014.    installation dependent and is not covered by this specification.
  1015.  
  1016. 3.10.2.  Responses
  1017.  
  1018.    240 article posted ok
  1019.    340 send article to be posted. End with <CR-LF>.<CR-LF>
  1020.    440 posting not allowed
  1021.    441 posting failed
  1022.  
  1023.  
  1024.  
  1025. Kantor & Lapsley                                               [Page 18]
  1026.  
  1027.  
  1028.  
  1029. RFC 977                                                    February 1986
  1030. Network News Transfer Protocol
  1031.  
  1032.  
  1033.    (for reference, one of the following codes will be sent upon initial
  1034.    connection; the client program should determine whether posting is
  1035.    generally permitted from these:) 200 server ready - posting allowed
  1036.    201 server ready - no posting allowed
  1037.  
  1038. 3.11.  The QUIT command
  1039.  
  1040. 3.11.1.  QUIT
  1041.  
  1042.    QUIT
  1043.  
  1044.    The server process acknowledges the QUIT command and then closes the
  1045.    connection to the client.  This is the preferred method for a client
  1046.    to indicate that it has finished all its transactions with the NNTP
  1047.    server.
  1048.  
  1049.    If a client simply disconnects (or the connection times out, or some
  1050.    other fault occurs), the server should gracefully cease its attempts
  1051.    to service the client.
  1052.  
  1053. 3.11.2.  Responses
  1054.  
  1055.    205 closing connection - goodbye!
  1056.  
  1057. 3.12.  The SLAVE command
  1058.  
  1059. 3.12.1.  SLAVE
  1060.  
  1061.    SLAVE
  1062.  
  1063.    Indicates to the server that this client connection is to a slave
  1064.    server, rather than a user.
  1065.  
  1066.    This command is intended for use in separating connections to single
  1067.    users from those to subsidiary ("slave") servers.  It may be used to
  1068.    indicate that priority should therefore be given to requests from
  1069.    this client, as it is presumably serving more than one person.  It
  1070.    might also be used to determine which connections to close when
  1071.    system load levels are exceeded, perhaps giving preference to slave
  1072.    servers.  The actual use this command is put to is entirely
  1073.    implementation dependent, and may vary from one host to another.  In
  1074.    NNTP servers which do not give priority to slave servers, this
  1075.    command must nonetheless be recognized and acknowledged.
  1076.  
  1077. 3.12.2.  Responses
  1078.  
  1079.    202 slave status noted
  1080.  
  1081.  
  1082. Kantor & Lapsley                                               [Page 19]
  1083.  
  1084.  
  1085.  
  1086. RFC 977                                                    February 1986
  1087. Network News Transfer Protocol
  1088.  
  1089.  
  1090. 4.  Sample Conversations
  1091.  
  1092.    These are samples of the conversations that might be expected with
  1093.    the news server in hypothetical sessions.  The notation C: indicates
  1094.    commands sent to the news server from the client program; S: indicate
  1095.    responses received from the server by the client.
  1096.  
  1097. 4.1.  Example 1 - relative access with NEXT
  1098.  
  1099.    S:      (listens at TCP port 119)
  1100.  
  1101.    C:      (requests connection on TCP port 119)
  1102.    S:      200 wombatvax news server ready - posting ok
  1103.  
  1104.    (client asks for a current newsgroup list)
  1105.    C:      LIST
  1106.    S:      215 list of newsgroups follows
  1107.    S:      net.wombats 00543 00501 y
  1108.    S:      net.unix-wizards 10125 10011 y
  1109.            (more information here)
  1110.    S:      net.idiots 00100 00001 n
  1111.    S:      .
  1112.  
  1113.    (client selects a newsgroup)
  1114.    C:      GROUP net.unix-wizards
  1115.    S:      211 104 10011 10125 net.unix-wizards group selected
  1116.            (there are 104 articles on file, from 10011 to 10125)
  1117.  
  1118.    (client selects an article to read)
  1119.    C:      STAT 10110
  1120.    S:      223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
  1121.            only (article 10110 selected, its message-id is
  1122.            <23445@sdcsvax.ARPA>)
  1123.  
  1124.    (client examines the header)
  1125.    C:      HEAD
  1126.    S:      221 10110 <23445@sdcsvax.ARPA> article retrieved - head
  1127.            follows (text of the header appears here)
  1128.    S:      .
  1129.  
  1130.    (client wants to see the text body of the article)
  1131.    C:      BODY
  1132.    S:      222 10110 <23445@sdcsvax.ARPA> article retrieved - body
  1133.            follows (body text here)
  1134.    S:      .
  1135.  
  1136.    (client selects next article in group)
  1137.  
  1138.  
  1139. Kantor & Lapsley                                               [Page 20]
  1140.  
  1141.  
  1142.  
  1143. RFC 977                                                    February 1986
  1144. Network News Transfer Protocol
  1145.  
  1146.  
  1147.    C:      NEXT
  1148.    S:      223 10113 <21495@nudebch.uucp> article retrieved - statistics
  1149.            only (article 10113 was next in group)
  1150.  
  1151.    (client finishes session)
  1152.    C:      QUIT
  1153.    S:      205 goodbye.
  1154.  
  1155. 4.2.  Example 2 - absolute article access with ARTICLE
  1156.  
  1157.    S:      (listens at TCP port 119)
  1158.  
  1159.    C:      (requests connection on TCP port 119)
  1160.    S:      201 UCB-VAX netnews server ready -- no posting allowed
  1161.  
  1162.    C:      GROUP msgs
  1163.    S:      211 103 402 504 msgs Your new group is msgs
  1164.            (there are 103 articles, from 402 to 504)
  1165.  
  1166.    C:      ARTICLE 401
  1167.    S:      423 No such article in this newsgroup
  1168.  
  1169.    C:      ARTICLE 402
  1170.    S:      220 402 <4105@ucbvax.ARPA> Article retrieved, text follows
  1171.    S:      (article header and body follow)
  1172.    S:      .
  1173.  
  1174.    C:      HEAD 403
  1175.    S:      221 403 <3108@mcvax.UUCP> Article retrieved, header follows
  1176.    S:      (article header follows)
  1177.    S:      .
  1178.  
  1179.    C:      QUIT
  1180.    S:      205 UCB-VAX news server closing connection.  Goodbye.
  1181.  
  1182. 4.3.  Example 3 - NEWGROUPS command
  1183.  
  1184.    S:      (listens at TCP port 119)
  1185.  
  1186.    C:      (requests connection on TCP port 119)
  1187.    S:      200 Imaginary Institute News Server ready (posting ok)
  1188.  
  1189.    (client asks for new newsgroups since April 3, 1985)
  1190.    C:      NEWGROUPS 850403 020000
  1191.  
  1192.    S:      231 New newsgroups since 03/04/85 02:00:00 follow
  1193.  
  1194.  
  1195.  
  1196. Kantor & Lapsley                                               [Page 21]
  1197.  
  1198.  
  1199.  
  1200. RFC 977                                                    February 1986
  1201. Network News Transfer Protocol
  1202.  
  1203.  
  1204.    S:      net.music.gdead
  1205.    S:      net.games.sources
  1206.    S:      .
  1207.  
  1208.    C:      GROUP net.music.gdead
  1209.    S:      211 0 1 1 net.music.gdead Newsgroup selected
  1210.            (there are no articles in that newsgroup, and
  1211.            the first and last article numbers should be ignored)
  1212.  
  1213.    C:      QUIT
  1214.    S:      205 Imaginary Institute news server ceasing service.  Bye!
  1215.  
  1216. 4.4.  Example 4 - posting a news article
  1217.  
  1218.    S:      (listens at TCP port 119)
  1219.  
  1220.    C:      (requests connection on TCP port 119)
  1221.    S:      200 BANZAIVAX news server ready, posting allowed.
  1222.  
  1223.    C:      POST
  1224.    S:      340 Continue posting; Period on a line by itself to end
  1225.    C:      (transmits news article in RFC850 format)
  1226.    C:      .
  1227.    S:      240 Article posted successfully.
  1228.  
  1229.    C:      QUIT
  1230.    S:      205 BANZAIVAX closing connection.  Goodbye.
  1231.  
  1232. 4.5.  Example 5 - interruption due to operator request
  1233.  
  1234.    S:      (listens at TCP port 119)
  1235.  
  1236.    C:      (requests connection on TCP port 119)
  1237.    S:      201 genericvax news server ready, no posting allowed.
  1238.  
  1239.            (assume normal conversation for some time, and
  1240.            that a newsgroup has been selected)
  1241.  
  1242.    C:      NEXT
  1243.    S:      223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.
  1244.  
  1245.    C:      HEAD
  1246.    C:      221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.
  1247.  
  1248.    S:      (sends head of article, but halfway through is
  1249.            interrupted by an operator request.  The following
  1250.            then occurs, without client intervention.)
  1251.  
  1252.  
  1253. Kantor & Lapsley                                               [Page 22]
  1254.  
  1255.  
  1256.  
  1257. RFC 977                                                    February 1986
  1258. Network News Transfer Protocol
  1259.  
  1260.  
  1261.    S:      (ends current line with a CR-LF pair)
  1262.    S:      .
  1263.    S:      400 Connection closed by operator.  Goodbye.
  1264.    S:      (closes connection)
  1265.  
  1266. 4.6.  Example 6 - Using the news server to distribute news between
  1267.       systems.
  1268.  
  1269.    S:      (listens at TCP port 119)
  1270.  
  1271.    C:      (requests connection on TCP port 119)
  1272.    S:      201 Foobar NNTP server ready (no posting)
  1273.  
  1274.    (client asks for new newsgroups since 2 am, May 15, 1985)
  1275.    C:      NEWGROUPS 850515 020000
  1276.    S:      235 New newsgroups since 850515 follow
  1277.    S:      net.fluff
  1278.    S:      net.lint
  1279.    S:      .
  1280.  
  1281.    (client asks for new news articles since 2 am, May 15, 1985)
  1282.    C:      NEWNEWS * 850515 020000
  1283.    S:      230 New news since 850515 020000 follows
  1284.    S:      <1772@foo.UUCP>
  1285.    S:      <87623@baz.UUCP>
  1286.    S:      <17872@GOLD.CSNET>
  1287.    S:      .
  1288.  
  1289.    (client asks for article <1772@foo.UUCP>)
  1290.    C:      ARTICLE <1772@foo.UUCP>
  1291.    S:      220 <1772@foo.UUCP> All of article follows
  1292.    S:      (sends entire message)
  1293.    S:      .
  1294.  
  1295.    (client asks for article <87623@baz.UUCP>
  1296.    C:      ARTICLE <87623@baz.UUCP>
  1297.    S:      220 <87623@baz.UUCP> All of article follows
  1298.    S:      (sends entire message)
  1299.    S:      .
  1300.  
  1301.    (client asks for article <17872@GOLD.CSNET>
  1302.    C:      ARTICLE <17872@GOLD.CSNET>
  1303.    S:      220 <17872@GOLD.CSNET> All of article follows
  1304.    S:      (sends entire message)
  1305.    S:      .
  1306.  
  1307.  
  1308.  
  1309.  
  1310. Kantor & Lapsley                                               [Page 23]
  1311.  
  1312.  
  1313.  
  1314. RFC 977                                                    February 1986
  1315. Network News Transfer Protocol
  1316.  
  1317.  
  1318.    (client offers an article it has received recently)
  1319.    C:      IHAVE <4105@ucbvax.ARPA>
  1320.    S:      435 Already seen that one, where you been?
  1321.  
  1322.    (client offers another article)
  1323.    C:      IHAVE <4106@ucbvax.ARPA>
  1324.    S:      335 News to me!  <CRLF.CRLF> to end.
  1325.    C:      (sends article)
  1326.    C:      .
  1327.    S:      235 Article transferred successfully.  Thanks.
  1328.  
  1329.    (or)
  1330.  
  1331.    S:      436 Transfer failed.
  1332.  
  1333.    (client is all through with the session)
  1334.    C:      QUIT
  1335.    S:      205 Foobar NNTP server bids you farewell.
  1336.  
  1337. 4.7.  Summary of commands and responses.
  1338.  
  1339.    The following are the commands recognized and responses returned by
  1340.    the NNTP server.
  1341.  
  1342. 4.7.1.  Commands
  1343.  
  1344.    ARTICLE
  1345.    BODY
  1346.    GROUP
  1347.    HEAD
  1348.    HELP
  1349.    IHAVE
  1350.    LAST
  1351.    LIST
  1352.    NEWGROUPS
  1353.    NEWNEWS
  1354.    NEXT
  1355.    POST
  1356.    QUIT
  1357.    SLAVE
  1358.    STAT
  1359.  
  1360. 4.7.2.  Responses
  1361.  
  1362.    100 help text follows
  1363.    199 debug output
  1364.  
  1365.  
  1366.  
  1367. Kantor & Lapsley                                               [Page 24]
  1368.  
  1369.  
  1370.  
  1371. RFC 977                                                    February 1986
  1372. Network News Transfer Protocol
  1373.  
  1374.  
  1375.    200 server ready - posting allowed
  1376.    201 server ready - no posting allowed
  1377.    202 slave status noted
  1378.    205 closing connection - goodbye!
  1379.    211 n f l s group selected
  1380.    215 list of newsgroups follows
  1381.    220 n <a> article retrieved - head and body follow 221 n <a> article
  1382.    retrieved - head follows
  1383.    222 n <a> article retrieved - body follows
  1384.    223 n <a> article retrieved - request text separately 230 list of new
  1385.    articles by message-id follows
  1386.    231 list of new newsgroups follows
  1387.    235 article transferred ok
  1388.    240 article posted ok
  1389.  
  1390.    335 send article to be transferred.  End with <CR-LF>.<CR-LF>
  1391.    340 send article to be posted. End with <CR-LF>.<CR-LF>
  1392.  
  1393.    400 service discontinued
  1394.    411 no such news group
  1395.    412 no newsgroup has been selected
  1396.    420 no current article has been selected
  1397.    421 no next article in this group
  1398.    422 no previous article in this group
  1399.    423 no such article number in this group
  1400.    430 no such article found
  1401.    435 article not wanted - do not send it
  1402.    436 transfer failed - try again later
  1403.    437 article rejected - do not try again.
  1404.    440 posting not allowed
  1405.    441 posting failed
  1406.  
  1407.    500 command not recognized
  1408.    501 command syntax error
  1409.    502 access restriction or permission denied
  1410.    503 program fault - command not performed
  1411.  
  1412. 4.8.  A Brief Word about the USENET News System
  1413.  
  1414.    In the UNIX world, which traditionally has been linked by 1200 baud
  1415.    dial-up telephone lines, the USENET News system has evolved to handle
  1416.    central storage, indexing, retrieval, and distribution of news.  With
  1417.    the exception of its underlying transport mechanism (UUCP), USENET
  1418.    News is an efficient means of providing news and bulletin service to
  1419.    subscribers on UNIX and other hosts worldwide.  The USENET News
  1420.  
  1421.  
  1422.  
  1423.  
  1424. Kantor & Lapsley                                               [Page 25]
  1425.  
  1426.  
  1427.  
  1428. RFC 977                                                    February 1986
  1429. Network News Transfer Protocol
  1430.  
  1431.  
  1432.    system is discussed in detail in RFC 850.  It runs on most versions
  1433.    of UNIX and on many other operating systems, and is customarily
  1434.    distributed without charge.
  1435.  
  1436.    USENET uses a spooling area on the UNIX host to store news articles,
  1437.    one per file. Each article consists of a series of heading text,
  1438.    which contain the sender's identification and organizational
  1439.    affiliation, timestamps, electronic mail reply paths, subject,
  1440.    newsgroup (subject category), and the like.  A complete news article
  1441.    is reproduced in its entirety below.  Please consult RFC 850 for more
  1442.    details.
  1443.  
  1444.       Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
  1445.       sdcsvax.UUCP
  1446.       Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
  1447.       Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
  1448.       !honman
  1449.       From: honman@unitek.uucp (Man Wong)
  1450.       Newsgroups: net.unix-wizards
  1451.       Subject: foreground -> background ?
  1452.       Message-ID: <167@unitek.uucp>
  1453.       Date: 25 Sep 85 23:51:52 GMT
  1454.       Date-Received: 29 Sep 85 09:54:48 GMT
  1455.       Reply-To: honman@unitek.UUCP (Hon-Man Wong)
  1456.       Distribution: net.all
  1457.       Organization: Unitek Technologies Corporation
  1458.       Lines: 12
  1459.  
  1460.       I have a process (C program) which generates a child and waits for
  1461.       it to return.  What I would like to do is to be able to run the
  1462.       child process interactively for a while before kicking itself into
  1463.       the background so I can return to the parent process (while the
  1464.       child process is RUNNING in the background).  Can it be done?  And
  1465.       if it can, how?
  1466.  
  1467.       Please reply by E-mail.  Thanks in advance.
  1468.  
  1469.       Hon-Man Wong
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481. Kantor & Lapsley                                               [Page 26]
  1482.  
  1483.  
  1484.  
  1485. RFC 977                                                    February 1986
  1486. Network News Transfer Protocol
  1487.  
  1488.  
  1489. 5.  References
  1490.  
  1491.    [1]  Crocker, D., "Standard for the Format of ARPA Internet Text
  1492.         Messages", RFC-822, Department of Electrical Engineering,
  1493.         University of Delaware, August, 1982.
  1494.  
  1495.    [2]  Horton, M., "Standard for Interchange of USENET Messages",
  1496.         RFC-850, USENET Project, June, 1983.
  1497.  
  1498.    [3]  Postel, J., "Transmission Control Protocol- DARPA Internet
  1499.         Program Protocol Specification", RFC-793, USC/Information
  1500.         Sciences Institute, September, 1981.
  1501.  
  1502.    [4]  Postel, J., "Simple Mail Transfer Protocol", RFC-821,
  1503.         USC/Information Sciences Institute, August, 1982.
  1504.  
  1505. 6.  Acknowledgements
  1506.  
  1507.    The authors wish to express their heartfelt thanks to those many
  1508.    people who contributed to this specification, and especially to Erik
  1509.    Fair and Chuq von Rospach, without whose inspiration this whole thing
  1510.    would not have been necessary.
  1511.  
  1512. 7.  Notes
  1513.  
  1514.    <1> UNIX is a trademark of Bell Laboratories.
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.  
  1523.  
  1524.  
  1525.  
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538. Kantor & Lapsley                                               [Page 27]
  1539.  
  1540.